準備這個系列的時候，我被問到一個問題：為什麼不選 Electron 而是 Godot？

我憑印象回答：有考慮過 Electron，但查了一下發現做不出透明效果，所以才找到 Godot。

後來我把之前與 AI 來回規劃對話翻出來，發現事情不是這樣。

那天我問過一樣的問題

當時開發還沒開始，我在對話裡詢問：

想穿插先問一下，godot 是最好的選項嗎？還是有其他建議？

它給了三個選項的比較。關於 Electron，它是這樣寫的：

如果你熟悉任何網頁技術（HTML/CSS/JS），Electron 的門檻會更低。透明視窗、動畫、計時器這些功能用 CSS 動畫和 JavaScript 都能輕鬆實現。最大的優勢是 Claude 對 JavaScript 的掌握程度遠高於 GDScript，協作效率會更好。

「透明視窗⋯都能輕鬆實現」。

AI 甚至指出 Electron 在協作上更有優勢，因為 AI 對 JavaScript 比對 GDScript熟。
缺點只有一個：打包後超過 100MB，因為包了一整個 Chromium，而且在 Steam 上會被玩家嫌。

所以「Electron 做不到透明」這件事，是我自己不知道從哪裡得到的印象，然後當成事實講出來。

推薦 Godot 的真正理由

同一則回答裡，AI 的結論是繼續用 Godot，理由有四個：

• 手繪 Sprite 動畫 —— AnimatedSprite2D 是內建節點，拖圖進去就能用
• 透明視窗置頂 —— Project Settings 裡勾選就完成
• 要上 Steam —— GodotSteam 是最成熟的整合方案之一
• 低資源佔用 —— 番茄鐘要常駐桌面，Electron 那樣吃資源不適合

AI 也講了 Godot 的缺點：GDScript 是小眾語言，AI 對它的熟悉程度不如 Python 或 JavaScript。

而這個缺點在之後就應驗了

「勾選就完成」這句話，代價是兩天

雖說 AI 在上面洋洋灑灑列了 4 個優點，但實際開發時卻不是這麼回事...

透明視窗確實在 Project Settings 裡有選項，但我整整卡了兩天才讓它真的透明。
透明設定確實在那裡，但「設定在那裡」和「新手能讓它生效」是兩回事，而這個差別在選型評估的時候很少會算進去。

Claude Code 與 Godot 4 的組合技

同一天，我還問了另一個問題：

想請問 Godot 4 可以跟 vscode 一樣和 claude 一同協作製作專案嗎？

它介紹了三種方式——Claude Code、Godot MCP Server、Godogen 技能包——然後建議我用最單純的組合：Godot 編輯器負責擺場景和素材，程式邏輯交給 Claude Code 寫 GDScript。

隔天我就去裝了 Claude Code，然後卡在 PATH 沒設定，claude 指令叫不出來。

所以我用 Claude Code 的起點，是一句「Godot 能不能像 VSCode 那樣跟 AI 協作」。

記憶會騙人，紀錄不會

這篇對我來說最重要的不是 Electron 能不能做透明，而是我記得「Electron 做不到」。這個記憶還很合理——它解釋了我為什麼繞去用遊戲引擎做桌面工具，聽起來像個有邏輯的決定。

但紀錄顯示，我知道 Electron 做得到的，但因為其他理由才選了 Godot

我的記憶把「當時的其他理由」擠掉，換上了一個更好講的版本。

這正是我為什麼要花時間把 git log、prompt 紀錄、規劃對話全部挖出來才動筆寫這個系列。我原本以為這些紀錄是用來補細節的，實際上它們好幾次是用來推翻我的印象。

如果你也打算寫自己的開發回顧，建議先去翻紀錄再寫，不要相信自己記得的版本。

帶走這個：把「否決理由」也寫下來，而且註明是查到的還是猜的

選型的時候我們都會記錄「為什麼選 A」，很少人記錄「為什麼不選 B」。而半年後通常會想知道的是後者。

紀錄理由就像是 ADR 寫在專案文件裡，格式可以參考：

第三欄是重點。「查到的」和「我猜的」如果不分開，半年後在記憶裡會長得一模一樣，而且都會變成「我當時評估過了」。

這次就是活生生的例子：我把一個沒查證的印象，記成了五個月前的評估結論，還很自信地講給 AI 聽。

明天講我在 Sproutimer 是怎麼下指令的——以及我翻完紀錄才發現的一件事：有些 prompt 根本不是我寫的。